Info-Mac 3/Info_Mac_1994-01.iso/Development/General/GCC 1.37.1r15/Documents/Hacking GCC

Text File | 1993-01-14 | 7KB | 136 lines

FOLDERS AND PATHS

The script "BuildGCCStages" assumes that the main GCC folder is one level up from
the folder it was in when executed.  If the script is anywhere else, then you will
need to pass the path to that main folder as a second argument to BuildGCCStages.
I recommend keeping all GCC stuff in a folder separate from MPW, but it's not required.

BISON

To rebuild GCC from scratch, you must first have Bison correctly installed.

[ptr to Bison versions]

REBUILDING

To do a basic recompilation, type "BuildGCCStages 1".  This will create a new folder
GCC.MPW.s1, copy the necessary files from GCC.MPW, and create "first stage"
(compiled by MPW C) tools, which can be put wherever you like.  The
process takes 15-20 minutes on a IIci.  The results are not quite as good as when
GCC compiles itself, but take a lot less time to produce and are fine for testing
changes.

To get the best versions, you have to use GCC to compile itself.  Three complete
compilations will be necessary, so do "BuildGCCStages 3".  On a IIci, it will run for
about two hours.  If you say "BuildGCCStages 4" instead, then it will do one more
self-compilation; the fourth-stage compiler should be *completely* identical to the
third stage.  If not, then something is wrong.  In any case, the third stage cpp and
cc1 (in GCC.MPW.s3) are the ones to use (drop them anywhere on your command path).

BuildGCCStages needs lots of extra diskspace, about 3Mb/stage over and above
the 8Mb of the source distribution.  Actually, each stage only really needs
the tools built in the previous stage, not the object or temp files, so they
could be deleted to save space.

If I'm rebuilding for experimentation, I usually just add GCC.MPW to the front of
my command path, to avoid the confusion of old versions getting used instead.  The
-tools option is also useful for this.

Another speedup is to use the "insn" target instead of "cc1" if only the machine
description "md" has been changed.  MPW makefiles have to do all the dependency
checking before starting execution, which means that they can't take advantage of
the fact that most of the insn-* files don't change when md is changed.  However,
if you make "insn" and then "cc1", the makefile will only have to recompile the
insn-* files that were actually changed by making "insn".

BUILDING GCC FOR 68000 and/or SANE

At present, one of GCC's unresolved bugs requires both -mc68020 and -mc68881 to be
turned on when compiling itself.  GCC is too slow to be particularly attractive on
older/slower Macs anyway, so this didn't seem like a real hardship. If you really
really need a 68000+SANE GCC, but don't care about having it be self-compiled, you
could build the first stage without -mc68020 and -mc68881 and use that; it is a little
slower, and some optimizations are missing, but otherwise works fine.

TESTING

This is an important step.  The folder Tests has a few programs that are small
enough to look at the assembly code, plus a version of dhrystone.  You should also
try using gC to build the programs in the MPW CExamples folder.  Of course, when
GCC successfully self-compiles, it is severely tested.  For test suites, we have
used the "C Torture Test" (available on various Internet servers) and the commercial
Plum-Hall test suite.

RETARGETING TO EXISTING MACHINES

To build GCC for other machines, create a folder GCC.<machine> and copy the desired
machine-specific files from the Machines folder.  The copies will be something like

    copy :Machines:<machine>.md :GCC.<machine>:md
    copy :Machines:tm-<machine>.h :GCC.<machine>:tm.h
    copy :Machines:out-<machine>.c :GCC.<machine>:aux-output.c
    copy :Machines:xm-<system>.h :GCC.<machine>:config.h

If you're working under MPW, then xm-mpw.h is almost always the correct file for
config.h.  However, you should examine the file to be sure (for instance, if you
don't want to support Apple's C dialect as the source language, then APPLE_C should
be undefined).

The makefile should be identical to that used by MPW GCC, although you may want to
change the programs' names from "cpp" and "cc1" to something else.  (Yes, cpp
is slightly different for different target machines; for one thing, it has a different
set of predefined symbols.)  The scripts gC and gCPlus invoking the compiler
will also need to be changed as appropriate.  (Giving them different names is a good
idea here too.)

RETARGETING TO NEW MACHINES

The first thing to do is to study both the GCC manual where it describes how to
retarget, as well as existing machine descriptions, particularly for those machines
with which you are familiar.  Unfortunately, there is no really crystal-clear
description of retargeting anywhere.

The easiest approach is to find an existing machine description that is closest
to the one you're interested, build the compiler so you know it will compile and
run correctly, then gradually mutate the description until you're generating code
for your machine.  Many of the more mysterious macros in tm.h are extremely
difficult to write correctly, and if too many are changed all at once, it becomes
well-nigh impossible to discover the cause of a compiler abort.

GCC INTERNALS

GCC is unusually well-written and well-documented, especially considering the size
and complexity of its intended task.  Nearly all of the machine-independent code
really is machine-independent, although its effectiveness falls off as one gets
further away from the VAX/68K/88K/Mips spectrum of machines and the Unix/Unix-lookalike
spectrum of operating systems.

The modifications that were made to get GCC to work under MPW fall into several
categories, each flagged by a distinct preprocessor symbol.

MPW is for those changes required by the MPW environment, independent of the compiler
used (typically #includes and file handling).  Most of these occur in contexts where
you'll also see USG (System V Unix), VMS, and MSDOS conditionals.  There are some
MPW_31 conditionals that are imagined (ahem) to work around bugs in MPW 3.1 only.

APPLE_C indicates those changes necessary to support Apple's dialect of C, such as
the pascal keyword and direct function definitions.  However, some changes to the
parser have not been so marked (since it gets run through bison).

MPW_C is for places in the GCC code that had to be changed to get the MPW C compiler
to handle them correctly.  Some of these are MPW_C31, for bugs that are supposed to
have been fixed in 3.2.

APPLE_HAX is for generic changes that would be worthwhile for any version of GCC.
Some of these remove GCC's limitations with respect to the MPW environment, such as
the need to import variables for each function, and work in conjunction with
bits of the target machine description.

TROUBLESHOOTING

There are two routines crucial to debugging - debug_dump_tree() is a one-argument
function that takes a tree structure and prints it on stderr, while debug_rtx()
does the same for rtl expressions.  These are especially useful to insert just
in front of a call to abort().